dewaldjacobsfandomcom-20200214-history
Service Inventory Alignment Framework
Document Overview Introduction Service Inventory pertains to information about the configuration of all installed services and inventory, and provides references to underlying resources and creates logical links between client installs and network information. It also provides links between service instances and client accounts. Service Inventory forms an integral part of the Service Fulfilment & Revenue Assurance offering. *It accumulates and stores current information about all services purchased by clients, *gives an effective visual representation of the services and inventory landscape, *enables business to understand client-to-service-to-inventory relationships. *It allows the visualization of the end-user services running on top of networks and to quickly locate resources associated with clients *make sure that the client is accurately billed. In short, it helps to significantly improve the client’s experience, optimize operations, and boost revenues. Benefits *Improve efficiency of fulfilment and assurance processes *Obtain an end-to-end view of client-to-service-to-inventory relations *Deliver a reusable framework that can be used by all affected business units to reduce data irregularities. *Will reduce configuration management issues and increase knowledge reliability. *Foster service quality and performance management processes *Facilitate the analysis of customer service usage and behaviour Purpose The purpose of this document is to act as a framework to improve SIA through the implementation and management of the framework components and processes. This SIA Framework will subsequently form part of the EA landscape as an artefact. The purpose also includes the inclusion of the roadmap that will serve as guidance for the execution and implementation of the SIAF. This document does not include actual business requirements but only serve the purpose as a framework by which to execute. Business Requirements will be drawn up based on each business entity analysis and iteration. The Framework The framework consists of four segmented areas. They are Systems, Inventory, Billing and Services. From each of these areas, it expands into more focus areas. The entire framework stands under the same governance as all other frameworks and should thus form part of the Enterprise Architecture landscape. Governance ensures that the programme is executed in line with corporate governance including IT-, operational-, corporate- and data governance. Security plays a vital part in executing the framework throughout the focus areas with success, ensuring validity and integrity. Security should be maintained and enforced throughout the framework. The framework execution starts with defining the SIA objectives that need to be reached. Stakeholder input is vital in the completion of the objectives. These stakeholders and subject matter experts include business managers, users, data owners. Once the objectives have been defined, the scope of the SIA programme gets defined in accordance with the objectives. Scope The scope of this framework includes all of the identified organizational areas that have a stake in the service inventory. Also included are the various architectural domains with Governance, BI and Data Quality, all to ensure that the alignment incorporates the SIA in full. The details of the scope of the roadmap will be addressed during the Portfolio Definition phase whereby a much clearer indication will highlight the required systems, business goals and stakeholders. To formalize the scope, the steering committee should identify the reasons why the SIA is required and what are the expected results. To achieve this, SIA issues should be analysed and current state can be used as a frame of reference to assist in the gap analysis to bring this scope into alignment with strategic requirements. This can only be achieved when the necessary stakeholders participate in workshops to determine the full extent of the problems and define the scope. The scope document known as the ‘as-is’ will clarify why SIA is needed, the results expected, implications of not continuing with the programme and any future justification for the implementation of the programme. To design the scope, stakeholder’s participation is crucial to establish current state, expectations and challenges that the programme faces. Only then can justification be given for expenditure and any savings or revenue generation advantages of the programme. Although the components of the framework will highlight many of the aspects of the scope, further scope implications will be identified as the programme gets implemented and executed. Benefits The benefits should include the life cycle: Preventive – To prevent and eliminates problems before they impact business processes, systems and data quality. Proactive – To analyse services and data to determine issues well in advance of any negative business impact. Reactive – Where proactive processes fail to prevent a problem and quickly react to unforeseen circumstances. Continuous – To provide regular reviews to ensure services and processes still provide expected value. Cost effective – Utilize the use of existing infrastructure resources, permitting to get more out of present inventory configuration. Objectives A carefully planned framework and subsequent policies and procedures will alleviate any risk of failure. Developing processes and technology that combines communication among different business functions will help to ensure high quality of configuration management information. The framework will allow the identified services, users, data, products, clients, systems, inventory and infrastructure aligned to business expectations and IT or existing services constraints. This framework will bring sales, billing and business leader decisions in line with complex IT and infrastructure priorities and goals. The right technologies will accelerate the discovery, design, development and deployment of the SIA programme across projects, systems and the enterprise. Issues/Risks Although risks will be determined during execution of each component within the framework and WBS, certain risks and issues can be determined before and covering the total framework. It is thus very important to compile a risk management plan on the same level as scope and objectives to list known issues and risks and to address them with the necessary controls. Typical risks include lack of resources, budgeting, technology, knowledge, and ever changing environments and applications, etc. Security A security policy and procedures are designed to mitigate risks such as operational, strategic and compliance to regulations as well as guide the allocation of CRUD roles to the resources and users of data within systems. Security should include the protection of the confidentiality, integrity and availability of information and granted access to resources, systems and corporate information. Governance Although the governance documents are expected to be completed and implemented within the organization, the SIA governance component addresses total organization wide governance policies and procedure adherence. In essence, the data governance encapsulates the entire range of policies, procedures and solutions developed within the SIA Framework. All aligned with corporate governance. Roadmap and Work Breakdown Structure Portfolio Definition Define Organization Alignment Achieving and sustaining organizational alignment needs a passionate, deep, and abiding commitment to define, achieve, and sustain organizational alignment throughout the organization as a part of the organization’s business strategies. KPI’s needs to be developed that will compare current and future measurements with a valuation approach to support the benefit value of alignment efforts and ROI. The results will include current state (As-Is), future state (To-Be), gap analysis and actions including corrective procedures that consistently complement the businesses strategic plans. With change management alignment strategies, tactics, and measurements to assure continued alignment throughout the change process. Additionally, change management must develop contingency plans to detect and remediate alignment issues before, during, and after change occurs. Organizational alignment cannot be a mere additional effort but needs to be maintained and supported on a high level and communicate alignment issues and results enterprise wide. Define Business Goal Alignment Business goal alignment describes the continuous process of utilizing resources to execute business objectives. These business goals are the stated milestones that we want the business to achieve. Define Stakeholder Alignment SIA requires a substantial investment of money, time, and resources. Therefore it is essential that short term initiatives yield high return on investments that meet stakeholder’s expectations. As soon as the stakeholders can see the advantage of investing in SIA, the long term objectives will have the support necessary. Identifying stakeholders will also enable communication channels with the right people at the right time. It is important to identify a point of reference for the SIA programme to be known to the stakeholders. People need to know where to go regarding any SIA related issues. SIA must be supported by everyone within the organisation, not just IT or relevant parties. Involving experts or domain experts from business is an essential step necessary for success. Each SIA participant should have a clearly defined role for making the initiative a success and must be accountable for their part. Define Project Alignment Project alignment is a strategic objective to place all business areas and project actors on a consistent platform with the final goals in mind. This will focus the efforts of all project areas into achieving the same final objective. Each business area may have its own specific tasks and methods but the end goal has to be the same. The first step in instituting project alignment is to identify and appraise the project goals. Agreement has to be reached as to what these goals are. The more participation each business area has in formulating goals the more invested they will be in achieving them. Prioritization is essential in completing a project on time. It should become an important consideration in creating the project goals. Having a strategic plan of goals to accomplish first gives the project direction and momentum. Priorities need to be set at the start of the project at each project stage. The second step towards project alignment is to establish the benefits it would bring to the company as a whole. This will be the motivation to drive improvement, innovation, and complete participation of everyone involved. The third step would be identifying the risks that concern the project. Knowledge of the difficulties and challenges expected will spur the creation of solutions and necessitate adjustments to the system or methods being used. Knowing the chance of success or failure helps business to prepare measures to reduce the risk and increase success. Precautionary measures may be taken and additional improvements done. The last stage of project alignment is the proper allocation of resources. Each segment of the project would need its specific funding, materials, and manpower. These resources should be properly managed and distributed to where they are needed. When allocating resources IS should also take into consideration the risks involved. Also keeping in mind other projects and future ventures would assist in the distribution of resources. The proper management and allocation of these resources is crucial to the cost-effectiveness and profitability of the project. Define EA Alignment Definition: “Enterprise Architecture (EA) is a strategic approach in the evolution of the system and services in response to the constantly changing needs of the organization. A common theme in all of the de finitions is that EA describes principles and guidelines in governing the implementation of information, technology and business mission in organizations; involving different stakeholders and processes. Enterprise Architecture is a blueprint for how an organization achieves the current and future business objectives. It examines the key business, information, application, and technology strategies and their impact on business functions. It provides the framework for planning and implementing a rich, standards-based, digital information infrastructure with well-integrated services and activities.” As the architectural landscape matures more and more, it becomes crucial for any business function to be aligned with the company’s architecture. Not to be seen as merely the planning but also to see the successful implementation of any programme initiated that involves Information technologies and solutions. To adhere to the architectural goals and processes, this SIA framework will have to form part of the bigger EA frameworks and processes. To understand how the integration takes place, a thorough alignment procedure will have to be executed and also accepted by the Architectural board. The knowledge from all programme initiatives should form part of the total corporate strategy. Thus playing a vital role in the top down approach of first defining goals and processes and then executing these defined processes.   Roadmap Identify After the Portfolio definition phase of aligning all the necessary stakeholders, processes, goals and company structures are completed, the identification of issues becomes the next step. With the knowledge of how the organization functions and where the need exists for SIA, it becomes clearer to identify the issues regarding service inventory. Therefore the identification of issues raised by the identified stakeholders will become the cornerstone of any efforts invested in the programme. When we look at the TQM concept of the cause and effect fishbone diagram, the design will have many heads (issues/problems) with many bones. This will form the guide for the rest of the project and subsequent projects. A thorough business requirements gathering by business analysts with identified stakeholders and domain experts in their business areas will accurately document all problems that exists. From these requirements, the next steps in the WBS can proceed and although completed, this step can at any time be revisited to asses new requirements that arise or that were not identified. Prioritize Once the issues and problems were identified, the issues can be prioritized from low to high importance. Role players in this phase will be the stakeholders and the various workgroups in accordance to business priorities. Typical attributes to take into account when prioritizing projects are High and low business value, high and low feasibility and high or low effort with the reusability of solutions or processes. The priorities will also list the business areas, audiences, benefits and insight into the processes that needs to be identified to resolve the issues. The project team with a project manager will determine the delivery dates and various project management methodologies that can be used to manage the sub projects. Scope The scope of work will be clear with the business requirements well documented. Defining the scope will not only look at the sub projects (issues) individually but should also align to the total SIA initiative. Scope will clearly indicate the range of issues and business impact. This is very crucial in the defining of problems and the subsequent solutions. Plan and Align to SIA Initiatives Under very rare circumstances will there ever be a situation where no initiatives already exist. All of these existing initiatives should be identified and documented to be aligned with the current SIA programme. These alignments are not limited to Service inventory systems but also to any other external system, process or business goal that will have direct or indirect impact on the SIA programme. Project Procedures Definitions The purpose of the definition section is to put the SIA programme into perspective within the organisation and other systems/projects. As the SIA programme consists of various projects, this subsection should describe the purpose of each project component of the larger SIA programme and how it combines to form the larger final solution.The definition phase will also include the implications that arise through the execution of this programme. It will also briefly outline the anticipated impact of the projects, considering the impact on users, sustainability, other projects, operational and strategic impacts, eg the use of the project to change aspects of the organisations culture, etc. With the consideration of the implications on the organisation itself and other teams, eg training, operational support, etc. As Is The “As-Is” should define the current state of business without any future solution considerations as this will be dealt with in the “To Be” with focus on the following (but not limited to) important requirements:• Understand the major processes within each business unit, how they interact, and how they contribute to the business’ success or failure. • Understand the transaction components of each process. • Determine who shares applications, to what extent, and how. • Determine satisfaction of services/systems and where they are dissatisfied, determine the barriers to improvement. • What are the contradictions between business unit requirements and present in alignment matrix with impact and GAP analysis? To Be During this phase it is important to understand that we need to focus on the desired outcome. This is the opposite of “As Is” in that now we do not look at the current state but focus on the expectations. What the solution should deliver.This is however not the completed solution but can be seen as the highest level of expectations. It is allowed to include unrealistic expectations and undeliverable needs that fall outside of any organisational goals or processes.This is where the utopia design is discussed and documented. Open brainstorm sessions will result in the desired expectation from stakeholders and as such should be managed and controlled.Although not necessarily delivering feasible solutions, this phase will be the main indicator into which direction the solution will go. Objectives What are the short and long term goals and objectives of SIA within with the organization? These should be documented in detail for each business unit or down to system/ process level together with identifying the metrics or KPI’s by which to measure success. As a subsection, compile the benefits relating to the projects and programme, how they will be measured, who will deliver it, when it will be delivered and who the benefits will be aimed at. The benefits will have to be developed together with the business units as the benefits belong to the business units. Scope This scope section should be completed for each of the sub projects within the SIA programme. As SIA has been previously defined by the framework on a programme level, detailed sub projects that are identified will need to be documented in full and follow the entire roadmap.Scope should clearly indicate what is included and what is excluded from the projects. Scope does not include the time or effort it will take to complete the projects.As the scope of each project will not be initially perfectly clear, it will have to allow for changes. An initial decision that needs to be made by all major stakeholders is to allow for a certain amount of scope creeping measured in time and effort. Defining expected deliverables, functionality, data and technical information will also assist in the accurate definition of scope. Business Rules Business rules commonly describe business constraints and define conditions and not processes. They define the conditions under which a process is carried out or the new conditions that will exist after a process has been completed. Specify a series of clear statements about the logic underlying the business unit and the conditions and constraints associated with such underlying logic. These business rules should be clear and understandable for any level of the organization to read and understand without losing detail. The business rule statements must be in a form that the business owner can immediately accept as valid or reject as invalid.Multiple business rules exist for each of the different programme projects. Clear and precise documentation of the will allow stakeholders and team members alike to have a better understanding of the conditions.  Stakeholders and Domain Experts Identification Stakeholder and domain expert identification seeks to identify all people and groups involved in the programme and sub projects. This identification is used in order to incorporate interests, expectations and participation of persons and groups to the programme. Stakeholders at different levels and business units have different motives and interests. It is of fundamental importance to analyse these interests and expectations. The stakeholders will participate from beginning right through to the handover phase. Therefore it is very important to not only select the right high level stakeholders, but also the subject matter experts and domain experts that will assist in defining and developing the solutions. Although the programme will have people that have a stake in the entire programme, stakeholders and domain experts will have to be identified for each sub project to manage and take ownership.   Management Throughout the programme we need to actively manage the stakeholder’s requirements and expectations. This requires an understanding of both formal and informal structure of the organisation involved. The reason why you need to do stakeholder management is to drive stakeholder satisfaction. This requires reliable, dependable, repeatable effort from your side. We need to know the needs and expectations of stakeholders and invest in those needs. A frequent investment (weekly, even daily) in the needs of the stakeholders helps projects to be successful. The amount of time allocated to Stakeholder Management depends on the size and difficulty of the project and the goals, the time you have available for communication, and the amount of help you need to achieve the results you want. Working through the list of stakeholders thinking through the levels of support and through the actions we would like them to perform. Group the stakeholders according to "Desired Support," "Desired Project Role," and "Actions Desired". Remember to let people know as early as possible of any difficult issues that may arise, and discuss with them how you can minimize or manage any impact. Although the focus is on stakeholders, the same criteria and management can be applied to domain experts. Report and Measure Audit The effective execution of the programme will require continuously assessing the quality of the solutions through audits done flowing through the various projects and programme as a whole. During the entire life cycle of the projects, it is important to evaluate its effectiveness against a set of identified metrics and KPI’s. Any weaknesses that are identified are prioritized against business requirements and improved and optimized. Regular audits will rationalise the programme into a more productive process that needs less resources with better processes monitoring and limiting failures. Progress Being able to measure, monitor and verify progress effectiveness throughout the SIA programme is essential in the active management and on-going programme improvement. The organization needs to formalize targets, measuring conformance and communicating concrete metrics to managers and stakeholders. Metrics provide a unified view of quality, and can also provide the basis for reporting. Monitoring and verification based on a well-defined set of metrics provides important knowledge about the value of the programme and the framework in use, and empowers business with the ability to determine how the programme can meet their own business needs. Monitoring needs to be done on the existing data misalignments and secondly on the current programme progress based on existing metrics designed. This coincides with the verification of effort through auditing processes done on the programme. Monitoring results can be presented in various forms from online dashboards to printed reports. BI Dashboards The SIA programme BI dashboard is a data visualization tool that displays the developed metrics and key performance indicators (KPIs) for the programme and each individual project, consolidated on a single screen. They may be tailored for a specific metrics targeted for a single SIA programme point of view, business department or project. Communication Communication consists of informing the stakeholders of progress through continuous feedback via acceptable channels. Throughout the programme it is essential to communicate the progress made and policies and standards implemented to the stakeholders. Various processes and system changes will be put in place and all of these process impacts need to be relayed to the stakeholders. It is essential to give training to system users on a regular basis as new processes get implemented and the impact of those changes on the behaviour of systems. Communication also includes the training of users on the various systems. Although monitoring of employees will indicate users that need extra training, regular informative material needs to be distributed to all employees on the progress and system implementations.   Corrective Procedures Root Cause Analysis (RCA) Root Cause Analysis (RCA) is a step by step method that leads to the discovery of a fault's first or root cause. Every failure has a various amount of causes. A RCA investigation traces the cause and effect trail from the end failure back to the root cause. It identify the relationships between different root causes. RCA requires looking beyond the solution to the immediate problem and understanding the fundamental or underlying cause(s). The subsequent solution could entail changes in procedures or processes or systems. It may also result in additional training of users on systems or to help them successfully implement business processes and adhere to procedures.The finding of the root cause of any fault or issue can be accomplished by using a Fault and Cause Tree analysis or even Fishbone diagrams Fault trees graphically represent the interaction of failures and causes together with other events within a system or process. Important factors to take into account:*What proof do you have that the problem exists? *How long has the problem existed? *What is the impact of the problem? *What sequence of events leads to the problem? *What conditions allow the problem to occur? *What other problems surround the occurrence of the central problem? *Break down a problem into small, detailed parts to better understand the big picture. *Were all the factors taken into account, obvious and not obvious? Procedures After completion of the root cause analysis, procedures and processes can be identified and created. This will be done based on all the information gathered during the previous steps. When the initial work was done correctly, the procedures will be clear and have to incorporate the entire programme and not just focused on the individual project(s). Procedures need to be developed together with the stakeholders as it will be the stakeholders and domain experts that will have the final say in the validity of the procedures and the subsequent signing off of the documents. Source Clean-up In any Information system that generates data, it is crucial to do data cleansing on existing incorrect data. This does not only adhere to the enterprises governance framework but also to the data quality management programme.For more detail in how to implement data quality within the SIA programme, view the DQ framework and processes. Solutions With the defined and accepted procedures in place, the desired solutions can be developed. The solutions can be business processes that need to change, training that needs to be done or software modifications to existing systems or even additional systems that needs to be developed. The desired solution will become clear as the necessary analysis documentation identifies feasible resolve and thus addressing the how, when and where. Best Practices Throughout the entire roadmap, certain best practices will be identified and documented. These best practices will minimize time and budget as they are implemented in further sub projects and will also form part of the architectural landscape for reusability. Best practises will become the benchmark to any other future endeavours relating to the SIA programme or similar projects.Although best practises will be applicable to a specific time and period, each iteration will identify new changes and improve the benchmark. With dynamic best practises, the organization is guaranteed to maintain a high quality of productivity and effectiveness in both systems and data. Align to DQ Framework All data related initiatives need to be aligned with the current organizational DQ framework. The well documented framework, standards and governance will ensure that the standards are met and governance maintained. Handover Procedures A detailed Project Handover Plan will be developed and will form part of the programme artefacts.Key components of the Detailed Project Handover Plan will include:*The project handover checklist - reviewed, amended and updated *Operation, Maintenance and Training manuals *The plan for weekly meetings to monitor compliance to the Handover Plan. *Define areas of responsibility and acceptance. *Clarify and define different phases of acceptance and handover. *Record items outstanding for phase or project completion on a punch list. *managing key stakeholders and domain experts including the group who will receive the handover *a clear date for handover of the project *a communication plan *change management issues and how these will be handled *developing appropriate training *clear risk management *having clear roles for the recipients in the department taking on the new work